Step FunctionsからECS RunTaskしようとしたら「ECS.AccessDeniedException」と出た時の対処法
こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。
みなさん、Step Functionsを使っていますか？
Workflow Studioで視覚的にステートマシンを組み立てるのが非常に楽しくて私は大好きです！
今回はAWSマネジメントコンソールからStep FunctionsでECE RunTaskのタスクを設定した時に以下のようなエラーが出た時の対処法を書かせていただきます！
User: arn:aws:sts::${アカウントID}:assumed-role/${ロール名}/hogehoge is not authorized to perform: iam:PassRole on resource: arn:aws:iam::${アカウントID}:role/${タスク実行ロール名} because no identity-based policy allows the iam:PassRole action (Service: AmazonECS; Status Code: 400; Error Code: AccessDeniedException; Request ID: hoge; Proxy: null)
忙しい方は「さっそく結論」の部分のみご確認ください。
さっそく結論
Step Functionsのステートマシンに設定しているIAMロールを確認しましょう。
以下のようにECSのタスク定義で設定しているタスク実行ロール（TaskExecutionRole）とタスクロールのパスロールの権限を付与するためのIAMポリシーが必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::${アカウントID}:role/${タスク実行ロールのID}",
"arn:aws:iam::${アカウントID}:role/${タスクロールのID}"
]
}
]
}
※ ${アカウントID}、${タスク実行ロールのID}、${タスクロールのID}はご自身の環境に合わせて変更してください。
参考記事まとめ
- iam:PassRoleって何？
- ECSのタスク実行ロールとタスクロールって何？
このエラーが発生した時の状況と原因
検証のため、AWSのマネジメントコンソールからステートマシンを作っていました。
Workflow Studioで視覚的に作っていきたいので進めていきます。
ECS RunTaskを実行するタスクを作っていきます。
Fargateタスクを実行するために、APIパラメーターを設定します。
{
"LaunchType": "FARGATE",
"Cluster": "arn:aws:ecs:ap-northeast-1:${アカウントID}:cluster/${クラスターID}",
"TaskDefinition": "arn:aws:ecs:ap-northeast-1:${アカウントID}:task-definition/${タスク定義}:${リビジョン}",
"NetworkConfiguration": {
"AwsvpcConfiguration": {
"Subnets": [
"${サブネットID}",
],
"SecurityGroups": [
"${セキュリティグループID}"
]
}
}
}
ちなみですが、NetworkConfiguration を指定し忘れて以下のようなエラーが発生することもよくあるので注意が必要です。（参考： Step Functions から ECS RunTask で Fargate を使用する時の注意点）
Network Configuration must be provided when networkMode 'awsvpc' is specified. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException; Request ID: hoge; Proxy: null)
問題なさそうですので、次へをクリックしました。
今回特にIAMロールを用意していなかったので、新しいロールの作成 を選択しています。
実行ロールは、完全な許可で作成されます。 と書いてくれています。これは安心ですね。（フリ）
CloudWatch Logsにログを出力するためのポリシーなどが生成されています。
良さそうなので「ステートマシンの作成」をクリックします。
この状態のままステートマシンを実行すると表題のエラーとともに失敗します。
User: arn:aws:sts::${アカウントID}:assumed-role/${ロール名}/hogehoge is not authorized to perform: iam:PassRole on resource: arn:aws:iam::${アカウントID}:role/${タスク実行ロール名} because no identity-based policy allows the iam:PassRole action (Service: AmazonECS; Status Code: 400; Error Code: AccessDeniedException; Request ID: hoge; Proxy: null)
原因と対策
Fargateのタスクを実行するにあたり、タスクロールとタスク実行ロールというIAMロールを指定します。
ざっくり表現すれば、以下のように今回作ったステートマシンからFargateのタスクを実行する際に、タスクロールとタスク実行ロールをECSに引き渡します。
「IAMロールを引き渡す」ためのPassRoleという権限がステートマシンに付与されたIAMロールになかったので失敗したと理解して良いと思います。
# 意訳: Step Functionsのステートマシンに付与されたIAMロールには、タスク実行ロールを引き渡すための権限がないから失敗したよ
User: arn:aws:sts::${アカウントID}:assumed-role/${ロール名}/hogehoge is not authorized to perform: iam:PassRole on resource: arn:aws:iam::${アカウントID}:role/${タスク実行ロール名} because no identity-based policy allows the iam:PassRole action (Service: AmazonECS; Status Code: 400; Error Code: AccessDeniedException; Request ID: hoge; Proxy: null)
ちなみに個人的にIAMのPassRoleについて最もわかりやすかった記事は以下の記事です。いまいちPassRoleとAssumeRoleがわからない方はぜひ見てください。
今回AWSのマネジメントコンソールから新規作成したステートマシン用のIAMロールにはPassRoleをするための権限がなかったため失敗してしまいました。
ということで、ステートマシンに付与しているIAMロールに以下のようにPassRoleを許可するIAMポリシーを付与することで、無事に実行が成功する様になりました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::${アカウントID}:role/${タスク実行ロールのID}",
"arn:aws:iam::${アカウントID}:role/${タスクロールのID}"
]
}
]
}
まとめ
- PassRoleという存在
- コンソール上に「実行ロールは、完全な許可で作成されます」と表示されるけど、権限が足りていなかった
「許可のIAMポリシーがないため○○の実行に失敗する」ということはよくありますが、PassRoleは存在を知らないとなぜ必要なのかわかりにくいこともあると思います。
この記事が誰かの役に立てれば幸いです。
